[Bugfix][Quantization] Don't claim the GPU lacks FP4 support when the checkpoint is weight-only - #53328

Purpose

prepare_nvfp4_moe_layer_for_marlin() warns unconditionally:

Your GPU does not have native support for FP4 computation but FP4 quantization is being used. Weight-only FP4 compression will be used leveraging the Marlin kernel. This may degrade performance for compute-heavy workloads.

But the Marlin NVFP4 MoE path is selected for two independent reasons, and the message only describes one of them:

1. the GPU genuinely lacks native FP4 cutlass support, or
2. the checkpoint is weight-only (W4A16_NVFP4 / MIXED_PRECISION, no FP4 activation scales), so a W4A4 cutlass kernel is inapplicable no matter how capable the GPU is.

In case (2) the warning is simply false, and it is emitted on hardware that does support native FP4.

This matters beyond cosmetics. The message is quoted as evidence that a GPU family lacks FP4 kernels, and it reads identically whether the cause is the silicon or the checkpoint — so a checkpoint-format property gets attributed to the hardware. On Jetson Thor (SM110) specifically, this warning has been circulating as evidence of missing SM110 FP4 kernels; it is not.

This PR gates the warning on cutlass_fp4_supported() — the same predicate the NVFP4 linear path already uses to pick its kernel — and states the weight-only case explicitly otherwise.

There is an identical unconditional warning in compressed_tensors/compressed_tensors_moe/compressed_tensors_moe_w4a4_mxfp4.py. I left it alone to keep this PR focused; happy to fold it in if you'd prefer one change.

Test Plan

Measured on a device that supports native FP4 but selects Marlin because of the checkpoint — Jetson AGX Thor (SM110), vLLM 0.27.1, CUDA 13.

Establish the device genuinely supports FP4:

torch.ops._C.cutlass_scaled_mm_supports_fp4(110)  # capability check behind cutlass_fp4_supported()
torch.ops._C.cutlass_group_gemm_supported(110)

Then serve two NVFP4 MoE checkpoints that differ only in whether activations are quantized, and compare the startup logs:

# weight-only (config carries W4A16_NVFP4)
vllm serve nvidia/NVIDIA-Nemotron-3.5-Lightning-30B-A3B-NVFP4

# true W4A4 (config_groups[*].input_activations num_bits=4)
vllm serve nm-testing/nvfp4_moe-e2e

Test Result

Device capability, before any model is loaded:

cutlass_scaled_mm_supports_fp4(110) = True
cutlass_group_gemm_supported(110)   = True

Same device, two checkpoints:

# weight-only checkpoint -> Marlin, and the warning fires (FALSE on this GPU)
Using 'MARLIN' NvFp4 MoE backend out of potential backends: [...]
Your GPU does not have native support for FP4 computation but FP4 quantization is being used. ...

# W4A4 checkpoint -> cutlass, no warning
Using FlashInferCutlassNvFp4LinearKernel for NVFP4 GEMM
Using 'VLLM_CUTLASS' NvFp4 MoE backend out of potential backends: [...]
(no warning)

The W4A4 run generates correctly through the cutlass path, confirming the GPU's FP4 support is real and the warning in the first run was wrong:

prompt:    "The capital of France is"
completion:" Paris. The capital of the United Kingdom is London. The capital of the
            United States is Washington, D.C. The"

With this patch the first case emits the info_once line instead of the warning, and the second case is unchanged (no message either way). Behaviour is otherwise identical — this only changes which message is logged.

I have not run the full test suite locally; this is a logging-only change with no functional path affected, but please let CI confirm.